As it is known in the art, integrated circuits may be designed to perform many complex logical functions and to serve as an interface between one or more external functional units, such as memory or another integrated circuit. As technology advances, the amount of functional logic able to be contained in one integrated circuit is constantly increasing.
As the density of functional logic within one integrated circuit increases, it becomes more important to eliminate any logical flaws since such flaws within a circuit may not be easily fixed without the expense and time delay associated with redesign and refabrication of the integrated circuit. Due to the rapidly advancing technology, additional time delays in manufacturing an integrated circuit are highly undesirable, because if many rebuilds of the integrated circuit are necessary before it can be assured that the integrated circuit is operating as expected, the integrated circuit may become obsolete. Therefore it is desirable to identify as many logical design problems within the integrated circuit before it is actually manufactured.
One method of accomplishing this task is by building a model in software of the integrated circuit. A test set is then developed to test various functional units of the model of the integrated circuit to ensure that the model and hence the integrated circuit operate as expected before it is manufactured. The test set is a data set representing data which is provided to the pins of the integrated circuit at different time intervals to simulate transactions on the external pins of the device which in turn exercise internal functions of the integrated circuit.
One method of developing a test set involves a designer identifying common transactions which the integrated circuit may perform. A transaction based simulator or a transactor is then used to simulate identified transactions by providing digital values representing signal values on the input pins of the structural model in a particular order. When the digital values are provided in the correct order, a given transaction may be simulated. For example, to transfer data into a model of an integrated circuit, the data is first provided to the input pins, and then clocks for the integrated circuit model are cycled to clock the data into the integrated circuit model.
For data busses with a more complex protocol, there may be additional steps necessary for transferring data. For example, a given bus protocol may require that for a write instruction, the initial data on the bus is the address, and data in the following cycle is data which is to be written to that address. The transactor responds to a write instruction by simulating the operation according to the bus protocol by depositing digital data values to the input pins of the integrated circuit model and clocking the digital data values into the integrated circuit model in the correct order. Instructions which cause signal values to be provided at the pins of the integrated circuit are commonly called `commander` and `responder` instructions.
The transactor uses the commander and responder instructions as follows. A structural model may have multiple ports, for example, a port which interfaces with a CPU and a port which interfaces with a memory. Here, for clarification, the bus which communicates with the CPU is termed Bus.sub.-- A and the bus which communicates with memory is termed Bus.sub.-- B. The commander instruction initiates a read by providing digital data values on the pins of Bus.sub.-- A of the model in the correct order to simulate a read request. The read command propagates to Bus.sub.-- B of the model. In response to signals provided on Bus.sub.-- B by the model, the responder instruction deposits digital data values on the pins of Bus.sub.-- B of the model. The digital data values provided on Bus.sub.-- B by the responder instruction correspond to the read data which would be supplied by a memory device in response to the read command. The read data is returned to Bus.sub.-- A of the model, and the read commander instruction verifies the results on the pins of Bus.sub.-- A against the expected results.
One problem associated with using a transactor to test an integrated circuit is that the tests that the transactor performs are generally manually generated, that is the person generating the test for the integrated circuit decides what functions need to be tested, and provides instructions which test the functions in the test set. When the integrated circuit is placed in the destination circuit board, however, design errors may be uncovered due to unforeseen interactions of different functions on the circuit board. These unforeseen interactions may be a result of many different functions happening simultaneously within the chip, rather than serially, as simulated by the manually generated test set.
One way to find all the design flaws within an integrated circuit is to build a structural model of the entire computer system, and attempt to find errors by executing actual system software. A drawback of this approach is that a structural model of the entire system has an enormous amount of gates, and consequently an enormous amount of memory is needed to store the structural model. Therefore, simulation runs using the structural model process instructions very slowly. Because it is desirable to have a fast turn-around time between error detection, error repair, and re-execution of tests, it is not feasible to use an entire system simulation to test the functionality of one gate array.